Currently, 3GPP is considering development of E-UTRA and E-UTRAN as set out in the technical specification 3GPP TS 36.300 v 8.1.0 (2007-06), incorporated herein by way of reference, and related documents. 3GPP Long Term Evolution (LTE) aims to enhance the Universal Mobile Telecommunications System (UMTS) standard, for example, by improving efficiency and services.
In E-UTRAN, user equipment (UE) communicates with a network node, NodeB (eNB), with data being sent on radio bearers (RBs) over a radio link between them. The eNB interfaces with a Mobile Management Entity/System Architecture Evolution Gateway (MME/SAE GW) via an interface designated as S1. An E-UTRAN network includes a plurality of eNBs and MME/SAE GWs.
In LTE, all the Radio Access Network (RAN) functions are integrated in each node, eNB. Downlink user data, that is Internet Protocol (IP) packets, are transmitted from the SAE GW to the eNB. As the UE is handed over from a first, source, eNB to second, target, eNB, the SAE GW is updated with the second eNB address and the SAE GW starts to send data to that target eNB.
However, to avoid data loss, any data that is already buffered in the source eNB must be forwarded to the target eNB. Also, data that has been sent to the source eNB during the handover (HO) procedure, before the SAE GW is updated with the new eNB address, is also forwarded by the source eNB to the target eNB.
To preserve the order of packets sent to the UE, the target eNB must strive to send data over the radio in the same order as sent by the SAE GW. That is, first data buffered by the eNB is sent to the target eNB, followed by data in transit from the SAE GW during the HO process, and only when these have all been sent should the target eNB send to the UE fresh data that it receives directly from the SAE GW.
The message flow for the HO process applied to a UE 1 is shown in FIG. 1, which illustrates a network including a source eNB 2, a target eNB 3 and an MME/SAE GW 4. When the source eNB 2 makes a handover decision based on measurement reports from the UE 1, it sends a Handover Request message, at step 4, to the target eNB 3. At the Admission Control step 5, the target eNB 3 configures the required resources and sends a Handover Request Acknowledge message, at step 6, to the source eNB 2. Following the Handover Command, at step 7, from the source eNB 2 to the UE 1, the UE 1 detaches from the old cell and synchronises to the new cell associated with the target eNB 3. Also, data packets buffered at the source eNB 2 and any in transit are forwarded to the target eNB 3 from the source eNB 2. Following the Handover Confirm message at step 10 from the UE 1 to the target eNB 3, a Handover Complete message, at step 11, is sent to the MME/SAE GW 4 by the target eNB 3. Data packets from the source eNB 2 continue to be delivered to the target eNB 3. Once all the forwarded data from source eNB 2 has been received by the target eNB 3, the target eNB 3 can then send to the UE 1 fresh data arriving over S1 from MME/SAE GW.
In LTE, the data forwarding phase, where data is sent to the target eNB from the source eNB, currently starts when the source eNB receives the Handover Request Ack message, at step 6 in FIG. 1, from the target eNB which indicates the end of the preparation phase for that target eNodeB.
However, it has recently been proposed that the source eNodeB 2 be able to trigger multiple preparation procedures towards several target eNodeBs 5 and 6, as shown in FIG. 2, where the same references are used for the same items. For the purposes of explanation, only two target eNBs are illustrated, but there may be more than two target eNBs available. The source eNB 2 sends Handover Request messages, at steps 4a and 4b, to the target eNBs 5 and 6. The source eNodeB 2 receives Handover Request Ack messages, shown at step 6a and step 6b, from each of the multiple target eNodeBs 5 and 6, but, at that time, does not know which of the target eNodeBs 5 and 6 will be finally selected as the one to which the UE 1 will hand over. The UE 1 will finally succeed in being handed over to only one of the target eNodeBs 5 and 6. Therefore, when the source eNodeB 2 receives the Handover Request Ack messages, at steps 6a and 6b, it does not know towards which of the target eNodeBs 5 and 6 it should trigger data forwarding.
There have been two previous proposals to deal with data forwarding where multiple target eNBs exist to ensure that the finally elected target eNodeB will receive the forwarded data.
In a first proposal, as shown in FIG. 3, the source eNodeB 2 triggers multiple data forwarding procedures towards all prepared target eNodeBs 5 and 6 from which it has received Handover Request Ack messages, at steps 6a and 6b. This approach is inefficient, cumbersome and bandwidth consuming, as it involves forwarding the data towards target eNodeBs which will not eventually be elected to form a connection with the UE.
In a second proposal, as shown in FIG. 4, the source eNodeB 2 triggers the data forwarding towards only a preferred target eNodeB 5 at the time it receives the Handover Request Ack messages at steps 6a and 6b. The preferred target eNB 5 may, for example, be that one having the highest probability of the UE 1 successfully handing over to it. The probability of success can be assessed in various ways, for example, based on channel quality. The manner in which a target eNB 5 is designated as the preferred target eNB depends on a particular implementation of a network. The source eNB 2 only triggers the data forwarding towards any other target eNodeB 6 if and when it gets an indication, on receipt of a Release Resource message at step 13, from that other non-preferred target eNodeB 6 that it has finally been selected by the UE 1. Thus, when one of the non-preferred target eNBs is finally selected, that indication to the source eNodeB 2 comes quite late in the handover process and makes the data forwarding process quite complex.